1. Field of the Invention
The present invention generally relates to media files and, more particularly, a universal digital video media file format.
2. Description of the Prior Art
Non-linear video and audio editing systems (NLE's) that can perform random access on the source material are typically set up on independent computer workstations having a means to input digital or analog audio and video as well as software for editing the inputted audio and video.
In the world of non-linear digital video editing, one of the constant problems faced by production facilities that employ a mixture of video editing products from competing vendors (such as Avid, Apple, Sony, Thomson-Grass Valley, and Adobe) is the fact that many video editing applications use proprietary and incompatible file formats. For instance, the two most popular video editing applications today—Avid and Final Cut Pro—the former captures or imports video files into the “omf” or “mxf” format, while the latter captures video in the Quicktime format. Neither application can natively play or manipulate the files created by the other.
Additionally, different vendors often have their own proprietary video CODECS (compression/decompression algorithms) that can reduce the size of video files so that they occupy less space and still maintain a usable quality.
It is somewhat helpful that there are certain standardized or publicly available CODECS that are supported by all vendors of digital video editing applications. Examples of such CODECS include, but are not limited to, “DV-25” (25 megabit Standard Definition Digital Video), “DV-50 (50 megabit Standard Definition Digital Video), “DV-100 (100 megabit High Definition Digital Video), and Sony's IMX formats (variants of MPEG-2).
However, despite the fact that competing vendors almost always support these standardized CODECS, one of the leading vendors of NLE applications—Avid—adds a proprietary wrapper to these standardized codecs when capturing files in those formats, and may split audio off into discreet files when it was originally embedded in a single data stream with the video. Avid essentially alters the presentation of standardized digital data, effectively making the format of the file as it is stored on disk incompatible with other competing applications. There may be other vendors who do similar things, although most vendors seem to allow video that's encoded in standardized formats to be stored in standardized ways that are compatible across most all applications.
To illustrate, if a TV station captures files in Avid's DV-50 format, after setting aside approximately 8 MB of space per second of video to store a file, other competing applications such as Apple's Final Cut Pro or Adobe Premiere or many third-party indexing and database tools cannot utilize the same file even though the essence of the digital data is something they support. Typically, if a video clip will be manipulated by Avid as well as other applications, duplicate video data must be captured multiple times and stored in multiple formats so that it can be used by the competing applications.
In order to avoid the inconvenience of having to capture or transcode and store multiple versions of the same video and audio data so that it could be used by Avid and other competing non-linear video editing applications, it would be desirable to have a system that permits a single set of video and audio files to be used by all applications and that enables this functionality automatically.
A current prior art solution include Apple's “Quicktime Reference File” built into its Quicktime format. A Quicktime Reference file is a small file (typically about 1 to 2 kilobytes) that can refer to non-Quicktime media files and make those media files appear as Quicktime files to applications that are able to read Quicktime files. So, for instance, Quicktime reference files can be created on a Windows or Macintosh OS computer such that Avid's “mxf” or “omf” files appear to be valid “Quicktime Files”.
Generally, Quicktime Reference Files are files having links to that audio and video media files that are NOT in the Quicktime format and that make those files appear to be in the Quicktime Format so that they can be played by any Quicktime-compliant applications.
All current Avid NLE applications include the ability to make Quicktime Reference Files. Even though Avid stores all its files in a proprietary formats, Avid provides a limited feature that allows clips or edited movies to be viewed via Windows or Mac-based Quicktime-compliant video application (such as another NLE or an encoding program)—provided that the freely distributable Avid CODECS are installed on the computer that will play the Quicktime Reference File, and provided that the computer has the Avid media files mounted. So Quicktime Reference Files are well known in the video editing and post production world.
However, there are some clear deficiencies in the way Avid and others create Quicktime Reference files such that the resulting Quicktime Reference Files are especially difficult to use in video editing applications.
First, while most professional video applications provide a means to embed the “source name” and “source timecode” in the metadata associated with captured video clips—which is crucial for many steps of the production process (e.g., re-capturing, archiving, “conforming” at high resolution a video originally edited at “draft resolution”) Avid's process of creating Quicktime reference files does not put the “source name” and “actual source timecode” in the reference file. Thus, when you open an Avid-produced Quicktime Reference File in Final Cut Pro, for instance, the starting timecode is always 00:00:00:00 for every clip, and there is no indication of what the original source was for the material. It is possible to put correct and accurate information source name and timecode in the Quicktime Reference File. Avid just chooses not to do it.
Another deficiency occurs in the “codec” information that gets put into the Quicktime Reference File. In specific, even though an original clip might have been captured in the “Avid DV25” format, if the Quicktime Reference File refers to the clip as being encoded in the “Avid DV25” codec (Avid's proprietary way of wrapping standardized DV25 files) instead of just standard “DV25”, then the application trying to play the Quicktime Reference File will decode the file using Avid's codec rather than the standardized codec. When not used from within Avid applications, Avid's codecs perform very poorly—typically video cannot be played in real time without stuttering, or playing video in real time causes excessive CPU utilization. Simply modifying the Quicktime Reference File to say the clip is encoded with the standard “DV25” codec instead of “Avid DV25” would allow the file to play back perfectly in a non-Avid NLE application. Yet, many programs that produce Quicktime Reference Files label data as being in the Avid proprietary format rather than being in the standardized format. The situation is identical for not only DV25 but also DV50 and DV100 (also known as DVC Pro HD).
A third deficiency is that most procedures to produce Quicktime Reference Files from Avid media clips are inconvenient and require many steps. Cumbersome procedures clearly deter many production facilities from using Quicktime Reference Files.
A fourth deficiency especially affects collaborative work environments that have central storage. Because Quicktime Reference Files typically refer to files that are by Avid users and not by the Quicktime Reference File users, there is a danger that the Quicktime Reference Files could become useless should the original files to which they refer get deleted by accident or should the original files get deleted deliberately by Avid editors who are finished using the original files and who are unaware that someone is still using them via Quicktime Reference Files.
A fifth deficiency is that until now, there has been no way to produce Quicktime Reference Files on the Linux® platform, in part because the inventor of Quicktime (Apple) does not have or has not distributed a toolkit that can create Quicktime Reference files on Linux®. Therefore, for a Linux-based storage system, currently the only way to make Quicktime® Reference Files on the system is via a Windows or Mac-based application that is connected to the Linux-based central storage.
It would be highly desirable to provide a system and method for correcting these deficiencies by allowing a single set of video and audio files to be used by all non-linear video editing applications automatically.